Dynamically analyzing third-party application website certificates across users to detect malicious activity

ABSTRACT

A verification server provides certificate verification services to users of third-party application sites. In some embodiments, a verifier component of a user&#39;s client device provides the verification server with a certificate of a third-party application site, and the verification server indicates whether the certificate is successfully verified. In response to successful verification, the verifier component of the user&#39;s client device takes an action such as permitting the user&#39;s credentials to be provided to the third-party application site. In some embodiments, verifier components of numerous client devices provide certificates to the verification server, based on which the verification server learns which certificates are valid for a given third-party application site.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/039,275, filed on Jul. 18, 2018 and entitled “Dynamically AnalyzingThird-Party Application Website Certificates Across users to DetectMalicious Activity,” which in turn claims the benefit of ProvisionalApplication No. 62/689,026, filed on Jun. 22, 2018, both of which areincorporated herein by reference.

FIELD OF ART

The present disclosure generally relates to the field of softwareapplications, and more specifically, to verification of third-partyapplication websites.

BACKGROUND

Many software applications are made available in web-based form, withapplication functionality being made available via web pages obtainedover computer networks. In such cases, there is a risk that the webpages may be tampered with, such as having pages substituted by amalicious party. Even where secure protocols such as HTTPS/TLS/SSL areemployed, techniques such as man-in-the-middle attacks can still be usedto inject spurious information ultimately leading to compromised userinformation.

If, for example, a malicious party can clandestinely provide a user witha modified version of a third-party application login page, themalicious party may be able to obtain the user's username/password orother credentials, thereby obtaining access to the user's account on thethird-party application. This problem is compounded if the user re-usescredentials on different services, so that the malicious third-party can(for example) also obtain access to a “master” service such as asingle-sign on service that provides access to the user's account onnumerous other applications, as well.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates one embodiment of a computing environment in whichusers use web-based third-party applications, and in which a serverprovides a verification service to ensure that third-party applicationsaccessed by the user are legitimate.

FIG. 2A illustrates a sequence of interactions between client devices ofusers, verifier components on the client devices, third-partyapplication sites, and the server, during a preliminary process oflearning legitimate third-party application certificates, according toone embodiment.

FIG. 2B illustrates a sequence of interactions between a user's clientdevice, a verifier component on the client device, a third-partyapplication site being accessed by the user, and the server, whenauthenticating the third-party application site, according to oneembodiment.

FIG. 3 is a high-level block diagram illustrating physical components ofa computer used as part or all of the verification server, clientdevice, or system providing the third-party application site, accordingto one embodiment.

The figures depict embodiments of the present invention for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles of the invention described herein.

DETAILED DESCRIPTION

FIG. 1 illustrates one embodiment of a computing environment in whichusers use web-based third-party applications available to thatorganization, and in which a server provides a verification service toensure that third-party applications accessed by the user arelegitimate.

Users use their client devices 120 (e.g., desktops, laptops, tabletcomputers, smartphones, or the like) to communicate directly orindirectly with third-party application sites 110 (e.g., SALESFORCE™,GOOGLE APPS™, or the like) to obtain pages of the application, such asfor login to the application, for using functionality of theapplication, etc.

The client devices 120 have a verifier component 125 that verifies thethird-party application sites 110, determining whether the certificatesof the sites have been modified, and taking responses based on theverification (e.g., permitting submission of user credentials via theweb pages of the third-party applications). In some embodiments, theverifier component 125 is authored by the organization responsible forthe verification server 100. In some embodiments, the verifier component125 is implemented as a browser plugin; in other embodiments in whichthe client device 120 has access to internet security data (e.g., TLS(Transport Layer Security) data), the verifier component is implementedas a security application that communicates with other applications.

The verification server 100 performs verification of third-partyapplications on behalf of client devices using the third-partyapplications, as described below.

The verification server 100 includes a certificate store 103 that storesrepresentations of verified third-party application site certificates(e.g., X.509 or equivalent certificates) in association with anidentifier of the third-party applications (e.g., their internetdomains, such as www.salesforce.com). The certificate representationsmay differ in different embodiments. For example, in some embodiments,the certificate representations are hash values of the certificates ofthe third-party application sites 110, as computed by a hash functionsuch as SHA (Secure Hash Algorithm). In other embodiments, thecertificate representations are the original certificates themselves. Insome embodiments, the certificate store 103 may include multipleverified certificates for a given third-party application; this allowsfor the use of proxy servers,

A certificate learning module 107 of the verification server 100populates the certificate store 103 based on certificate representationsreceived from the verifier components 125 of multiple client devices120. Obtaining the certificate representations from multiple clientdevices 120 (which are typically located in different locations,operating at different times, etc.) allows the certificate learningmodule to identify genuine certificates and screen out tampered-with orotherwise spurious certificates, given that in most instances at mostonly a small minority of certificates provided to client devices 120 arespurious. The certificate learning module 107 may employ differentlearning techniques in different embodiments. For example, in someembodiments the learning is rules-based, applying a predetermined rule,such as selecting (as the verified certificate representation for agiven application) the certificate representation that is provided in atleast some given percentage of instances (e.g., 95%), or at least somegiven number of times (e.g., 300 times), or the like. The certificatelearning module 107 may be continuously run so as to keep knowledge ofthe certificates up-to-date, thereby accounting for changes incertificates over time.

The verification server 100 further includes a verifier component 104that verifies that a given third-party application 110 is legitimate,using the certificate store 103. The verifier component 104 receives,from the verifier component 125 on the client device 120, an identifierof the third-party application and a representation of the certificatethat stores representations of verified third-party application sitecertificates (e.g., X.509 or equivalent certificates) in associationwith an identifier of the third-party applications (e.g., their internetdomains, such as www.salesforce.com). (The identifier of the third-partyapplication may be included within the certificate itself, such as anX.509 subject name field, or it may be separate, such as the domain nameportion of a URL of the third-party application site 110.) The verifiercomponent 104 determines, for a given site certificate, whether arepresentation of the site certificate matches one of the verified citecertificate representations already stored in the certificate store inassociation with the third-party application corresponding to the sitecertificate. In some embodiments, if there is no match, then theverifier component 104 determines that the third-party application isnot verified. In other embodiments, to accommodate situations in whichthe certificate learning module 107 has obtained too few certificatesfor the particular third-party application site 110 to be able to learna verified certificate for that third-party application site, theverifier component 104 considers a given certificate to be verified ifno verified certificate representations have yet been associated withthe third-party application site 110. In some embodiments, theverification server 100 stores a set of trusted certificates (e.g., oneset for each organization that uses the services of the verificationserver 100, or one set for each user), and upon a request to verify thecertificate of a third-party application site 110, the verificationserver first checks whether the certificate is within the set of trustedcertificates (e.g., for the current user, or the organization to whichthe current user belongs), and if so considers the certificate to beverified, only proceeding to check the certificates in the certificatestore 103 if the certificate is not in the appropriate set of trustedcertificates.

In some embodiments, the verification server 100 (e.g., the user loginmodule 108 described below), or verifier component 125 of the clientdevice 120, takes additional security measures, in addition to (orpossibly instead of) the certificate verification of the verificationperformed by the verifier components 104 and 125. As a first example, insome embodiments the verifier component 104 populates a threats database109 based on prior certificate verification failures, identifying andstoring a set of geolocations of client devices 120 for whichcertification verification failed (e.g., within a particular recenttimeframe, such as the past day) on some client devices. The verifiercomponent 104 consults the threats database 109, comparing thegeolocation of the client device 120 requesting certificate verificationwith those geolocations in the threats database; if the geolocation isfound in the threats database 109 (e.g., within a given recenttimeframe), then the verification server 100 enforces more stringentsecurity measures, such as requiring multifactor authentication (MFA)before permitting the user of the client device 120 to be logged intothe third-party application site 120 from which the certificate came.

As a second example, in some embodiments the verification server 100stores, for each organization or user, a configurable security policybased on which the verifier component 125 may modify its behavior. Forexample, if the security policy for an organization mandatescertificates of at least a certain security level (e.g., those withsufficiently long keylengths, certain issuers, or certain cryptographicalgorithms), then the verifier component 125 will not permit the user ofthe client device 120 to logged into the third-party application site110 associated with a certificate not meeting the given security level,regardless of whether the certificate would otherwise be successfullyverified by the verifier component 104.

The verifier component 125 of the client device 120 takes actions inresponse to receiving a determination from the verifier component 104 ofthe server 100 of whether or not a given certificate is verified. Forexample, in some embodiments the verifier component 125 permits theclient device 120 (e.g., a browser thereof) to submit credentials of theuser to the third-party application site providing the certificate onlyif the certificate is determined to be verified; otherwise, the verifiercomponent 125 does not permit the submission of such credentials,thereby protecting the credentials from possible theft or other misuse.Prevention of submission of credentials is accomplished in various waysin different embodiments, such as by modifying the document object model(DOM) of the login page of the third-party application site 110, e.g.,by adding an overlay to the elements of the page to prevent pageinteraction, or changing the textual inputs of the login page to beread-only and the login or other credential submission button to bedisabled, and/or by intercepting any outgoing web requests correspondingto the pages of the site 110. In some embodiments, the actions uponfailure to verify a certificate include initiating the use of a virtualprivate network (VPN) connection in order to mitigate risk. Morespecifically, upon failure to verify a certificate the verifiercomponent 125 initiates a VPN connection for its client 120 with atrusted server (e.g., the verification server 100, or a server of theorganization to which the user of the client device 120 belongs) anduses the VPN connection for communication with the third-partyapplication sites 110. To do so, the verifier component 125 may, uponfailure to verify an application certificate, request establishment of aVPN connection and ensure that the VPN connection is active, communicatewith the third-party application site 110 again, and if the certificatepresented by the third-party application site 110 is verified, ceaseusing the VPN connection for subsequent communications with the site 110during that session.

In some embodiments, the actions of the verifier component 125 aredetermined using additional contextual data. As one example, in someembodiments the contextual data includes a location of the client device120 at time of verification, such as a geolocation obtained from theclient device itself (e.g., GPS coordinates) or derived from an IPaddress of the client device. Upon failure to verify a certificate of athird-party application site 120, the verifier component 125 identifiesone or more location(s) associated with an organization to which theclient device belongs (e.g., by consulting the organization-userdatabase 101) and compares those locations to the location of the clientdevice. If the location of the client device 120 corresponds to any ofthe identified locations of the associated organization, then the clientdevice is presumably within the network of the organization, in which aman-in-the-middle proxy may be being legitimately used; accordingly, insuch cases the actions of the verifier component 125 upon verificationfailure can be, for example, to provide a warning to a user of theclient device about the verification failure but to nonetheless permitthe client device to submit user credentials to the third-partyapplication 110. In some embodiments, the verification server 100associates locations with organizations by monitoring locations fromwhich client devices 120 associated with the various organizations haveaccessed the verification server 100 in the past.

As another example, in some embodiments the contextual data includes asecurity level of the third-party application site 110 to which theclient device 120 is logging in. For example, the verification server100 may store, for different third-party application sites 110, anassociated security level of that site, e.g., with each organizationbeing able to specify its own security level for the sites 110. Uponfailure to verify the certificate of an application site 110, theactions that the verifier component 125 takes are based upon thesecurity level for the site 110. For example, for a site with a highsecurity level, failure could lead the verifier component 125 to preventthe client device 120 from providing user credentials to the site 110;for a site with a low security level, the verifier component could allowuser credentials to be provided to the site 110, but just log associateddata (e.g., certificate data, IP address, etc.) and/or notify anadministrator of the organization of the verification failure.

As another example, in some embodiments the contextual data includes thelogin successes of others within the organization of the client device120. For example, in some embodiments the verification server 100 storesdata about the verification attempts of various users and theirorganizations. Upon failure to verify the certificate of a particularthird-party application site 110 for a particular user of a particularorganization, the verifier component 125 determines (e.g., by consultingthe verification server 100) whether other users of the sameorganization have had the certificate of the that third-partyapplication site 110 successfully verified by the verification server,e.g., within some recent past time window. If so, then the verifiercomponent 125 notifies the user of the client device 120 that otherswithin the same organization are having successful logins (which is apossible indication that user is at a location encountering aman-in-the-middle attack).

In some embodiments, the verification server 100 includes a statisticsgenerator 105 that logs data on the certificates provided forthird-party application sites 110, and whether those certificates weredetermined by the verifier component 104 to be verified, and generatesassociated statistics. For example, in some embodiments the verificationserver 100 logs features corresponding to each certificate provided bythe verifier component 125 to the server 100, such as an identifier ofthe third-party application site (e.g., the domain name of its URL), theinternet protocol (IP) address of the client device 120, the location ofthe client device (e.g., a geolocation such as GPS coordinates, or alocation derived from the IP address), and/or the current time, as wellas whether the verifier component 104 determined that the certificatewas verified. These logged features can then be used for purposes suchas identifying factors correlated to inauthentic certificates, such asparticular geolocations.

In some embodiments, the statistics generator 105 additionally storesinformation on the certificates that can be used to generate reports,e.g., on industry security trends. For example, the statistics generator105 can log certificate data such as cryptographic algorithms used,keylengths, root certificate authorities (CAs) used, the frequencies atwhich certificates change, and the like.

Note that the verification server 100, although depicted as a singlelogical system in FIG. 1, may be implemented using a number of distinctphysical systems and the connections between them, such as applicationservers, database servers, load-balancing servers, routers, and thelike.

The third-party applications 110 may be created by different applicationdevelopers. The third-party applications 110 are typically hostedentirely or partially on a server(s) located at a remote location fromthe client devices 120 and made available via a network 140, such as theInternet. In one embodiment, the third-party application's userinterface is implemented in HTML, or other web-based technology and isrendered within browsers of the client devices of the users, or within acustom application installed on the client devices. Although the term“third-party application” is used herein since for the typicalorganization the majority of applications that a user uses are authoredby different organizations, it is appreciated that the “third-partyapplications” could also include applications created and/or hosted byorganizations employing users of the client devices 120, or anorganization responsible for the verification server 100.

The network 140 may be any suitable communications network for datatransmission. In an embodiment such as that illustrated in FIG. 1, thenetwork 140 uses standard communications technologies and/or protocolsand can include the Internet. In another embodiment, the entities usecustom and/or dedicated data communications technologies.

In some embodiments, the verification server 100 provides services inaddition to page verification. For example, in one embodiment theverification server 100 provides single sign-on (SSO) services to usersof the client devices 120, recording the third-party application sites110 that are available to each user and automating user sign-on for eachof the user's third-party application sites. In such embodiments, theserver 100 has a user login module 108 that it uses to enable a user tolog in to the server 100 (e.g., using username/password or other form ofcredentials, which may require multi-factor authentication), therebyestablishing the identity of the user and (based on the identity of theuser) the organization to which the user belongs.

In embodiments in which the server 100 provides SSO services, the server100 additionally has an organization-user database 101 that describesproperties of the different organizations to which the server 100provides support, as well as properties of the users of thoseorganizations. For example, in one embodiment, the database 101 storesat least, for each organization, a unique identifier of theorganization, a list of unique user identifiers for the users of theorganization, and unique identifiers of various third-party applicationsites 110 to which the organization—or groups within the organization,such as an “Accounting” group—provides access. Similarly, the database101 stores at least, for each user of the organization, one or moreindicators of the third-party application sites 110 to which that userhas access. The indicators may be direct indicators of the third-partyapplication sites 110 (e.g., a unique identifier of an application),and/or indirect indicators, such as identifiers of organization groupsto which the user belongs, where the database 101 further storesidentifiers of the third-party applications to which the organizationgroups have access.

In embodiments in which the server 100 provides SSO services, the server100 also has an application login database 102 that specifies, for eachsupported third-party application site 110, configuration data thatspecifies the manner in which the application expects login to proceed.For example, in one embodiment in which the Security Assertion MarkupLanguage (SAML) is used, the application login database 102 specifies,for each supported third-party application 110, an Assertion ConsumerService (ACS) URL to which a SAML assertion will be sent via HTTP POST,an identifier of an entity issuing the SAML request, and anidentification of the audience for which the SAML assertion is intended.As another example, in an embodiment in which Open ID Connect (OIDC) isemployed, the data for a particular login flow might store a clientidentifier for the application 110, a client secret indicating how theapplication can exchange a token via a backchannel flow, metadata (e.g.,application name and/or logo), and one or more redirect URLs to which toreturn after the user has successfully established a session with theserver 100. The application login database 102 enables the server 100 tofollow the format expected by the federated sign-on protocols employedwhen logging in a given user to each of the user's third-partyapplications 110. For example, in the case of OIDC, during the flow thethird-party application will provide the client identifier, a state, anonce value, and OIDC arguments to specify the response type, and isreturned a code that the application can exchange for a token toidentify the user via a backchannel.

In embodiments in which the server 100 provides SSO services, the server100 further includes a remote login service 106 that uses theapplication configuration data from the application login database 102to communicate with third-party application sites 110 in order tofacilitate the user login, transparently providing the users with accessto the applications, even when the users are not already logged into theapplications. The remote login service 106 initiates operations thateffect the necessary steps for automatic SSO-based login of the user'sclient device 120 into the desired third-party application 110. Forexample, the remote login service 106 can specify a series of HTTPredirect operations as needed to obtain and verify session or othersecurity information via cookies, to transfer the request to thethird-party application, etc.

The user's client device 120 contacts the remote login service 106 aspart of an attempt to login to a third-party application site 110. Forexample, a browser of the user's client device 120 may display aweb-based user interface produced by the server 100 as a result of theuser logging into the server and showing icons or other visualindications of the third-party applications 110 to which the user'sorganization has granted the user access; when the user clicks on orotherwise selects one of the visual indications, the browser of theclient device 120 requests content for a URL of the remote login service106 (e.g., http://login.server.com/login?app=myapp.com/login, wherelogin.server.com is a domain of the server 100, and myapp.com/logincorresponds to the third-party application 110).

FIG. 2A illustrates a sequence of interactions between client devices ofusers, verifier components on the client devices 120, third-partyapplication sites, and the server, during a preliminary process oflearning legitimate third-party application certificates, according toone embodiment.

Client devices 120 request 205 pages of third-party application sites110 by specifying the URLs of those pages. For example, in embodimentsin which the server 100 provides SSO services, following successfullogin of the user to the server the server may provide links to thethird-party application sites 110 that a given user is allowed toaccess, and user selection of those links cause the user's client device120 to request the corresponding sites' pages.

In response to the requests, the third-party application sites 110provide 210 the requested pages. If the pages are secure (e.g., for alogin page using HTTPS), the sites 110 also provide a certificate.

The verifier component 125 sends corresponding certificaterepresentations (e.g., the certificates themselves, or a hash such asSHA (Secure Hash Algorithm), or other fingerprint thereof) to the server100, and an identifier of the application corresponding to thecertificate (which may be part of the certificate itself).

After a sufficient number of certificate representations have beenreceived for a given application, the certificate learning module 107selects one or more of the certificate representations as verifiedcertificate representations for the application and stores them in thecertificate store 103.

FIG. 2B illustrates a sequence of interactions between a user's clientdevice, a monitoring component on the client device, a third-partyapplication site being accessed by the user, and the server, whenauthenticating the third-party application site, according to oneembodiment.

A client device 120 requests 255 a page of a third-party applicationsite, such as a login page including functionality for the submission ofuser credentials.

In response, the third-party application site provides 260 the requestedpage, and also a corresponding certificate.

The verifier component 125 of the client device 120 sends 265 arepresentation of the certificate, and an identifier of the applicationcorresponding to the certificate, to the server 100. The server 100determines whether the certificate is verified, as described above withrespect to the verifier component 104 of FIG. 1. If the certificate isverified, the server 100 notifies 275 the verifier component 125 of theverification. In turn, the verifier component accordingly permits 280submission of user credentials to the third-party application site 110.

The techniques described above provide a number of advantages overalternate possible approaches. When the certificate learning module 107is continuously employed, the result is updating of certificateinformation in real-time, thereby automatically accounting for changesin application certificates without depending on certificate issuers toprovide valid certificates (which could lead to certificates beingupdated slowly, or not at all). When the server 100 has a large userbase providing certificates—e.g., as in embodiments in which the server100 provides SSO services to the users of many organizations—thelearning of verified certificates tends to be prompt and accurate.

FIG. 3 is a high-level block diagram illustrating physical components ofa computer 300 used as part or all of the verification server 100,client device 120, or system providing the third-party application site110, according to one embodiment. Illustrated are at least one processor302 coupled to a chipset 304. Also coupled to the chipset 304 are amemory 306, a storage device 308, a graphics adapter 312, and a networkadapter 316. A display 318 is coupled to the graphics adapter 312. Inone embodiment, the functionality of the chipset 304 is provided by amemory controller hub 320 and an I/O controller hub 322. In anotherembodiment, the memory 306 is coupled directly to the processor 302instead of the chipset 304.

The storage device 308 is any non-transitory computer-readable storagemedium, such as a hard drive, compact disk read-only memory (CD-ROM),DVD, or a solid-state memory device. The memory 306 holds instructionsand data used by the processor 302. The graphics adapter 312 displaysimages and other information on the display 318. The network adapter 316couples the computer 300 to a local or wide area network.

As is known in the art, a computer 300 can have different and/or othercomponents than those shown in FIG. 3. In addition, the computer 300 canlack certain illustrated components. In one embodiment, a computer 300acting as a server may lack a graphics adapter 312, and/or display 318,as well as a keyboard or pointing device. Moreover, the storage device308 can be local and/or remote from the computer 300 (such as embodiedwithin a storage area network (SAN)).

As is known in the art, the computer 300 is adapted to execute computerprogram modules for providing functionality described herein. As usedherein, the term “module” refers to computer program logic utilized toprovide the specified functionality. Thus, a module can be implementedin hardware, firmware, and/or software. In one embodiment, programmodules are stored on the storage device 308, loaded into the memory306, and executed by the processor 302.

Embodiments of the entities described herein can include other and/ordifferent modules than the ones described here. In addition, thefunctionality attributed to the modules can be performed by other ordifferent modules in other embodiments. Moreover, this descriptionoccasionally omits the term “module” for purposes of clarity andconvenience.

Other Considerations

The present invention has been described in particular detail withrespect to one possible embodiment. Those of skill in the art willappreciate that the invention may be practiced in other embodiments.First, the particular naming of the components and variables,capitalization of terms, the attributes, data structures, or any otherprogramming or structural aspect is not mandatory or significant, andthe mechanisms that implement the invention or its features may havedifferent names, formats, or protocols. Also, the particular division offunctionality between the various system components described herein ismerely for purposes of example, and is not mandatory; functionsperformed by a single system component may instead be performed bymultiple components, and functions performed by multiple components mayinstead performed by a single component.

Some portions of the above description present the features of thepresent invention in terms of algorithms and symbolic representations ofoperations on information. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. These operations, while describedfunctionally or logically, are understood to be implemented by computerprograms. Furthermore, it has also proven convenient at times, to referto these arrangements of operations as modules or by functional names,without loss of generality.

Unless specifically stated otherwise as apparent from the abovediscussion, it is appreciated that throughout the description,discussions utilizing terms such as “determining” or “displaying” or thelike, refer to the action and processes of a computer system, or similarelectronic computing device, that manipulates and transforms datarepresented as physical (electronic) quantities within the computersystem memories or registers or other such information storage,transmission or display devices.

Certain aspects of the present invention include process steps andinstructions described herein in the form of an algorithm. It should benoted that the process steps and instructions of the present inventioncould be embodied in software, firmware or hardware, and when embodiedin software, could be downloaded to reside on and be operated fromdifferent platforms used by real time network operating systems.

The present invention also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored on acomputer readable medium that can be accessed by the computer. Such acomputer program may be stored in a non-transitory computer readablestorage medium, such as, but is not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, magnetic-optical disks,read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, application specific integratedcircuits (ASICs), or any type of computer-readable storage mediumsuitable for storing electronic instructions, and each coupled to acomputer system bus. Furthermore, the computers referred to in thespecification may include a single processor or may be architecturesemploying multiple processor designs for increased computing capability.

The algorithms and operations presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may also be used with programs in accordancewith the teachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will be apparent to those ofskill in the art, along with equivalent variations. In addition, thepresent invention is not described with reference to any particularprogramming language. It is appreciated that a variety of programminglanguages may be used to implement the teachings of the presentinvention as described herein, and any references to specific languagesare provided for invention of enablement and best mode of the presentinvention.

The present invention is well suited to a wide variety of computernetwork systems over numerous topologies. Within this field, theconfiguration and management of large networks comprise storage devicesand computers that are communicatively coupled to dissimilar computersand storage devices over a network, such as the Internet.

Finally, it should be noted that the language used in the specificationhas been principally selected for readability and instructionalpurposes, and may not have been selected to delineate or circumscribethe inventive subject matter. Accordingly, the disclosure of the presentinvention is intended to be illustrative, but not limiting, of the scopeof the invention, which is set forth in the claims.

What is claimed is:
 1. A computer-implemented method performed on aclient device, the computer-implemented method comprising: requesting,by a web browser for a user, a web page of a third-party application website; receiving the web page and a corresponding certificate from thethird-party application web site; computing, by a plugin of the webbrowser of the client device, a fingerprint of the certificate; sending,by the plugin to a server, the fingerprint of the certificate and anidentifier of the third-party application; receiving, by the plugin fromthe server, an indication that the fingerprint of the certificatematches a known fingerprint of a certificate of the third-partyapplication that was reported to the server by client devices other thanthe client device, the reporting being performed by plugins of webbrowsers of the client devices other than the client device; andresponsive to receiving the indication, automatically sending, by theplugin without express user confirmation, credentials of the user to thethird-party application.
 2. A non-transitory computer-readable storagemedium storing executable instructions that when executed by a processorof a client device perform actions comprising: requesting, for a user, aweb page of a third-party application web site; receiving the web pageand a corresponding certificate from the third-party application website; sending, to a server by a verifier component of the client device,a representation of the certificate and an identifier of the third-partyapplication; receiving an indication from the server that therepresentation matches a stored certificate representation of thethird-party application; and responsive to receiving the indication,permitting, by the verifier component, credentials of the user to beprovided to the third-party application.
 3. The non-transitorycomputer-readable storage medium of claim 2, the actions furthercomprising computing a fingerprint of the certificate as the certificaterepresentation.
 4. The non-transitory computer-readable storage mediumof claim 2, wherein the verifier component is a web browser plugin. 5.The non-transitory computer-readable storage medium of claim 2, whereinthe client device is a smartphone, and the verifier component is asecurity application installed on the smartphone.
 6. The non-transitorycomputer-readable storage medium of claim 2, further comprising:requesting, for a user, a web page of a second third-party applicationweb site; receiving the web page and a corresponding second certificate;sending, to the server by the verifier component of the client device, asecond representation of the second certificate and an identifier of thesecond third-party application; receiving a second indication from theserver that the second representation fails to match a storedcertificate representation of the second third-party application.
 7. Thenon-transitory computer-readable storage medium of claim 6, furthercomprising: responsive to receiving the second indication: initiating avirtual private network (VPN) connection with a trusted server, usingthe VPN connection to communicate with the second third-partyapplication, receiving a third certificate from the second third-partyapplication website, sending, to the server by the verifier component ofthe client device, a third representation of the third certificate andan identifier of the second third-party application, receiving a thirdindication from the server that the third representation matches astored certificate representation of the second third-party application,and responsive to receiving the third indication, ceasing to use the VPNconnection for communication with the second third-party applicationsite.
 8. A computer-implemented method performed on a client device, thecomputer-implemented method comprising: requesting, for a user, a webpage of a third-party application web site; receiving the web page and acorresponding certificate from the third-party application web site;sending, to a server by a verifier component of the client device, arepresentation of the certificate and an identifier of the third-partyapplication; receiving an indication from the server that therepresentation matches a stored certificate representation of thethird-party application; and responsive to receiving the indication,permitting, by the verifier component, credentials of the user to beprovided to the third-party application.
 9. The computer-implementedmethod of claim 8, further comprising computing a fingerprint of thecertificate as the certificate representation.
 10. Thecomputer-implemented method of claim 8, wherein the verifier componentis a web browser plugin.
 11. The computer-implemented method of claim 8,wherein the client device is a smartphone, and the verifier component isa security application installed on the smartphone.
 12. Thecomputer-implemented method of claim 8, further comprising: requesting,for a user, a web page of a second third-party application website;receiving the web page and a corresponding second certificate; sending,to the server by the verifier component of the client device, a secondrepresentation of the second certificate and an identifier of the secondthird-party application; receiving a second indication from the serverthat the second representation fails to match a stored certificaterepresentation of the second third-party application.
 13. Thecomputer-implemented method of claim 12, further comprising: responsiveto receiving the second indication: initiating a virtual private network(VPN) connection with a trusted server, using the VPN connection tocommunicate with the second third-party application, receiving a thirdcertificate from the second third-party application website, sending, tothe server by the verifier component of the client device, a thirdrepresentation of the third certificate and an identifier of the secondthird-party application, receiving a third indication from the serverthat the third representation matches a stored certificaterepresentation of the second third-party application, and responsive toreceiving the third indication, ceasing to use the VPN connection forcommunication with the second third-party application site.